<!DOCTYPE html>
            
<HTML>
<HEAD>
<meta name="booktitle" content="Developing Applications With Objective Caml" >
 <meta charset="ISO-8859-1"><meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0">
<META name="GENERATOR" content="hevea 1.05-7 of 2000-02-24">
<META NAME="Author" CONTENT="Christian.Queinnec@lip6.fr">
<LINK rel=stylesheet type="text/css" href="videoc-ocda.css">
<script language="JavaScript" src="videoc.js"><!--
//--></script>
<TITLE>
 Introduction
</TITLE>
</HEAD>
<BODY class="regularBody">
<A HREF="book-ora149.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="index.html"><IMG SRC ="contents_motif.gif" ALT="Contents"></A>
<A HREF="book-ora152.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
<HR>

<H2> Introduction</H2>Chapters <A HREF="index.html#chap-PM">14</A> and <A HREF="index.html#chap-POO">15</A> respectively presented two
models of application organisation: The functional/modular model and
the object model. These two models address, each in its own way, the
needs of application development:<BR>
<BR>
<UL>
<LI>
 logical organisation of a program: module or class;

<LI> separate compilation: simple module;

<LI> abstract data types: module (abstract type) or object;

<LI> reuse of components: functors/sharing of types with parametric polymorphism or inheritance/subtyping with parameterized classes;

<LI> modifiability of components: late binding (object).
</UL>
The development of a modular application begins by dividing it into
logical units: modules. This is followed by the actualization of
their specification by writing their signature, and finally by
implementation. During the implementation of a module, it may be
necessary to modify its signature or that of its parameters; it is
then necessary to modify their sources. This is unsatisfactory if the
same module is already used by another application. Nevertheless,
this process offers a strict and reassuring framework for the
programmer.<BR>
<BR>
In the object model, the analysis of a problem results in
the description of the relations between classes. If, later
on, a class does not provide the required functionality, it is always
possible to extend it by subclassing. This process permits the reuse
of large hierarchies of classes without modifying their sources, and
thus not modifying the behavior of an application that uses them,
either. Unfortunately, this technique leads to code bloat, and poses
difficulties of duplication with multiple inheritance.<BR>
<BR>
Many problems necessitate recursive data types and operations which
manipulate values of these types. It often happens that the problem
evolves, sometimes in the course of implementation, sometimes during
maintenance, requiring an extension of the types and operations.
Neither of these two models permits extension in both ways. In the
functional/modular model, types are not extensible, but one can create
new functions (operations) on the types. In the object model, one can
extend the objects, but not the methods (by creating a new subclass
on an abstract class which implements its methods.) In this respect,
the two models are duals.<BR>
<BR>
The advantage of uniting these two models in the same language is to
be able to choose the most appropriate model for the resolution of the
problem in question, and to mix them in order to overcome the
limitations of each model.<BR>
<BR>
<HR>
<A HREF="book-ora149.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="index.html"><IMG SRC ="contents_motif.gif" ALT="Contents"></A>
<A HREF="book-ora152.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
</BODY>
</HTML>
